Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

🔍 Comprehensive PR Review

PR: #1257 — fix(workflows): pass globalSearchPath to all discoverWorkflowsWithConfig callers
Reviewed by: 2 specialized agents (code-review, test-coverage)
Date: 2026-04-16

Summary

This is a minimal, targeted fix that threads { globalSearchPath: getArchonHome() } to four previously-missing discoverWorkflowsWithConfig call sites — three in command-handler.ts (list, reload, run) and one in api.ts (GET /api/workflows). The fix is correct, surgical, and consistent with the existing CLI reference pattern. Tests are properly updated.

Verdict: ✅ APPROVE

🟡 Medium Issues (No Blockers — Follow-up Recommended)

1. Pre-existing gap: validate.ts missing globalSearchPath

📍 packages/cli/src/commands/validate.ts:90-93

archon validate workflows calls discoverWorkflowsWithConfig without globalSearchPath, so global workflows in ~/.archon/.archon/workflows/ are silently excluded from validation output. Same root cause as #1138. Out of scope for this PR — recommend a follow-up issue.

const { workflows: workflowEntries, errors: loadErrors } = await discoverWorkflowsWithConfig(
  cwd,
  loadConfig,
  { globalSearchPath: getArchonHome() }  // getArchonHome already imported nearby
);

2. Pre-existing gap: orchestrator-agent.ts:1434 no-codebase fallback missing globalSearchPath

📍 packages/core/src/orchestrator/orchestrator-agent.ts:1434

Inside handleWorkflowRunCommand, the "no project, exactly one codebase" fallback calls discoverWorkflowsWithConfig without globalSearchPath. A global workflow invoked through this narrow path would fail to resolve (returns undefined). Bounded impact: only fires when conversation has no codebase_id AND exactly one codebase is registered. Out of scope — follow-up.

discovery = await discoverWorkflowsWithConfig(workflowCwd, loadConfig, {
  globalSearchPath: getArchonHome(), // already imported
});

3. Test assertions use expect.any(String) instead of pinning the actual getArchonHome() value

📍 command-handler.test.ts:1044, api.workflows.test.ts:119

The CLI reference test at workflow.test.ts:313 demonstrates the tighter pattern — mock getArchonHome to a fixed path and assert that exact value. The @archon/paths mock in command-handler.test.ts doesn't export getArchonHome, so a regression to an empty/wrong path wouldn't be caught. Also, only the list call site has a signature-assertion test; reload and run don't.

// 1. Add to @archon/paths mock block (~line 194 in command-handler.test.ts):
getArchonHome: mock(() => '/home/test/.archon'),

// 2. Tighten existing list assertion:
expect(spyDiscoverWorkflows).toHaveBeenCalledWith(
  expect.any(String),
  expect.any(Function),
  { globalSearchPath: '/home/test/.archon' }
);

// 3. Add reload + run signature tests (same pattern):
test('should pass globalSearchPath on reload', async () => {
  await handleCommand(conversationWithCodebase, '/workflow reload');
  expect(spyDiscoverWorkflows).toHaveBeenCalledWith(
    expect.any(String), expect.any(Function), { globalSearchPath: '/home/test/.archon' }
  );
});

✅ What's Good

• Correct scope discipline: Only the 4 broken call sites were touched; CLI and orchestrator global paths were not disturbed.
• Import hygiene: getArchonHome added cleanly to existing @archon/paths import in command-handler.ts; no duplicate import needed in api.ts (already there).
• Test updates are accurate: Both test assertions correctly extend to 3-arg form — will catch structural regressions.
• No type regressions: Zero as any, full type safety via the optional third param.
• Consistent style: All 4 updated call sites use identical 3-line format matching CLI reference.
• Pre-existing @archon/workflows integration test: loader.test.ts exercises discoverWorkflowsWithConfig with a real globalSearchPath directory — strong confidence in underlying behavior.

📋 Suggested Follow-up Issues

Next Steps

1. ✅ This PR is ready to approve and merge — no blocking issues
2. 📝 Create follow-up issue for validate.ts + orchestrator-agent.ts:1434 (same root cause as Global workflows invisible to webhook commands and web UI #1138)
3. 🎯 Optionally tighten test assertions in this PR or defer to the follow-up

Reviewed by Archon comprehensive-pr-review workflow
Artifacts: ~/.archon/workspaces/coleam00/Archon/artifacts/runs/bd4c902d9ec93a1b33751c278b909d8e/review/

Self-Fix Report (Aggressive)

Status: COMPLETE
Pushed: Changes pushed to archon/task-fix-1138-global-workflows
Commit: ecd0640
Philosophy: Fix everything unless clearly a new concern

Fixes Applied (5 total)

Validation

Type check | Lint | Tests
✅ | ✅ | ✅ All packages pass

Self-fix by Archon · aggressive mode

Archon PR Validation Report

Verdict: APPROVE

Summary

Global workflows in ~/.archon/.archon/workflows/ were confirmed invisible on the Web UI and webhook commands (main branch). The fix — adding { globalSearchPath: getArchonHome() } to 6 call sites — resolves the issue completely. E2E testing verified the fix across Web UI grid display, search, and direct API response with no regressions.

Bug Confirmation

Fix Quality

• Code: 5/5 — mechanical, minimal, mirrors existing CLI pattern exactly
• Tests: 3 test files updated, 2 new tests added
• Audit: All 7 discoverWorkflowsWithConfig call sites verified, no remaining gaps

Issues

No blocking issues found.

Validated by archon-validate-pr workflow